Systems and methods for processing credits for distance-based insurance policies

ABSTRACT

Methods and systems for processing credits for customers having distance-based insurance policies for vehicles. According to aspects, a distance-based insurance policy of a vehicle specifies an amount of distance units for insured vehicle travel and has an associated policy term. Upon expiration of the policy term, an insurance provider receives an odometer reading and uses the odometer reading to calculate an amount of unused distance units. The insurance provider may determine one or more types of credit that are based on the amount of unused distance units. The insurance provider may also apply the one or more types of credit to an account of the customer.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.61/775,652, filed Mar. 10, 2013, which is incorporated by referenceherein.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to vehicle insurance policiesand, more particularly, to systems and methods for processing variouscredits resulting from distance-based insurance policies.

BACKGROUND

Vehicle or automobile insurance exists to provide financial protectionagainst physical damage and/or bodily injury resulting from trafficaccidents and against liability that could arise therefrom. Typically, acustomer purchases a vehicle insurance policy for a policy rate having aspecified term. In exchange for payments from the insured customer, theinsurer pays for damages to the insured which are caused by coveredperils, acts, or events as specified by the language of the insurancepolicy. The payments from the insured are generally referred to as“premiums,” and typically are paid on behalf of the insured over time atperiodic intervals. An insurance policy may remain (or have a status orstate of) “in-force” while premium payments are made during the term orlength of coverage of the policy as indicated in the policy. Aninsurance policy may “lapse” (or have a status or state of “lapsed”),for example, when premium payments are not being paid, when a cash valueof a policy falls below an amount specified in the policy, or if theinsured or the insurer cancels the policy.

Various vehicle insurance providers offer “distance-based” insurancewhereby a customer purchases an insurance policy that offers coveragefor a specified amount of distance units. For example, onedistance-based insurance policy may offer coverage for 100 miles oftravel by a particular vehicle. These vehicle insurance policies mayalso have an associated policy term. Referring back to the example, the100 miles of coverage may have a policy term of one (1) month. However,in situations in which a particular customer has unused distance unitsat the end of the policy term, the particular customer is notappropriately credited or refunded.

Accordingly, there is an opportunity for systems and methods to processcredits associated with distance-based vehicle insurance policies. Inparticular, there is an opportunity for systems and methods to processcredits that are commensurate with any unused distance units associatedwith distance-based vehicle insurance policies.

SUMMARY

In an embodiment, a computer-implemented method of crediting customershaving vehicle insurance policies is provided. The method includesfacilitating a purchase transaction with a customer for a distance-basedinsurance policy associated with a vehicle, a coverage provided by thedistance-based insurance policy (1) is based on an expiration odometervalue defined as the sum of an initial odometer reading of the vehicleand an amount of distance units specified by the insurance policy, and(2) expires at a pre-determined time. The method further includes,responsive to the pre-determined time expiring, receiving a subsequentodometer reading of the vehicle and, based on the subsequent odometerreading, determining that the expiration odometer value has not beenreached. Moreover, the method includes applying a credit to an accountof the customer.

In another embodiment, a system for crediting customers having vehicleinsurance policies is provided. The system includes a communicationmodule adapted to communicate data, a memory adapted to storenon-transitory computer executable instructions, and a processor adaptedto interface with the communication module. The processor is configuredto execute the non-transitory computer executable instructions to causethe processor to facilitate a purchase transaction with a customer for adistance-based insurance policy associated with a vehicle, a coverageprovided by the distance-based insurance policy (1) is based on anexpiration odometer value defined as the sum of an initial odometerreading of the vehicle and an amount of distance units specified by theinsurance policy, and (2) expires at a pre-determined time. Theprocessor is further configured to, responsive to the pre-determinedtime expiring, receive a subsequent odometer reading of the vehicle and,based on the subsequent odometer reading, determine that the expirationodometer value has not been reached. Moreover, the processor isconfigured to apply a credit to an account of the customer.

BRIEF DESCRIPTION OF THE DRAWINGS

The figures described below depict various aspects of the system andmethods disclosed herein. It should be understood that each figuredepicts an embodiment of a particular aspect of the disclosed system andmethods, and that each of the figures is intended to accord with apossible embodiment thereof. Further, wherever possible, the followingdescription refers to the reference numerals included in the followingfigures, in which features depicted in multiple figures are designatedwith consistent reference numerals.

FIG. 1 depicts an example environment including components and entitiesassociated with processing credits associated with distance-basedvehicle insurance policies in accordance with some embodiments.

FIG. 2 depicts an example diagram associated with processing creditsassociated with distance-based vehicle insurance policies in accordancewith some embodiments.

FIGS. 3A-3D depict example interfaces associated with reviewing andselecting credits associated with distance-based vehicle insurancepolicies in accordance with some embodiments.

FIG. 4 depicts a flow diagram associated with processing creditsassociated with distance-based vehicle insurance policies in accordancewith some embodiments.

FIG. 5 is a block diagram of a processing server in accordance with someembodiments.

DETAILED DESCRIPTION

The novel systems and methods disclosed herein relate generally toprocessing vehicle insurance policies. In particular, the systems andmethods relate to crediting customers having distance-based insurancepolicies through insurance provider. According to certain aspects, adistance-based insurance policy for a vehicle is defined by a certainamount of distance units and a policy term or expiration time. Eachdistance unit corresponds to a certain distance that is travelable bythe vehicle. Accordingly, the vehicle and a customer associated with thevehicle (e.g., the vehicle owner or operator) may be covered by theinsurance policy while the policy term is in force and as long as thevehicle does not travel in excess of the amount of distance units.

Although some customers will meet the distance unit limit during thepolicy term, there will also be instances in which customers have abalance or remainder of unused distance units upon expiration of thepolicy term. According to the present embodiments, the systems andmethods are configured to process credits or refunds according to theunused distance units. Upon expiration of a policy term for a particulardistance-based insurance policy, the insurance provider may query thevehicle or customer for an odometer reading and compare that odometerreading to an expiration odometer value that is calculated when thecustomer purchases the distance-based insurance policy. If there areunused distance units, then the customer may be due some form of creditor refund. According to aspects, the credit may be in the form of“rollover” distance units, monetary credit or cash, credit with theinsurance provider, various discounts or offers, and/or other types ofcredit.

The systems and methods therefore offer a benefit to customers byrewarding credit that corresponds to what is effectively unusedinsurance coverage. Accordingly, customers may be incentivized topurchase distance-based vehicle insurance, especially in situations inwhich the customers may otherwise operate a vehicle without insurance.Further, insurance providers may be able to attract more customersand/or process more insurance policies.

Although the following text sets forth a detailed description ofnumerous different embodiments, it should be understood that the legalscope of the invention is defined by the words of the claims set forthat the end of this patent. The detailed description is to be construedas exemplary only and does not describe every possible embodiment, asdescribing every possible embodiment would be impractical, if notimpossible. One could implement numerous alternate embodiments, usingeither current technology or technology developed after the filing dateof this patent, which would still fall within the scope of the claims.

FIG. 1 depicts an example environment 100 associated with processingvarious types of credits associated with distance-based vehicleinsurance policies. Although FIG. 1 depicts certain entities,components, and devices, it should be appreciated that additional oralternate entities and components are envisioned.

As illustrated in FIG. 1, the environment 100 includes a vehicle 105that may be any type of car, automobile, truck, motorcycle, fleet ofvehicles, marine vessel, or other vehicle capable of being driven oroperated by a driver or operator. The vehicle 105 has an electronicdevice 106 associated therewith. In some cases, the electronic device106 may be installed as an on-board dash of the vehicle 105, such aspart of an original equipment manufacturer (OEM) installation on thevehicle 105. In other cases, the electronic device 106 may belong to adriver or operator of the vehicle 105 (generally, a “vehicle operator”).For example, the electronic device 106 may be a smartphone of thevehicle operator. It should be appreciated that other types ofelectronic devices are envisioned, such as notebook computers, tablets,GPS devices, and/or the like.

The electronic device 106 can be configured to communicate with aninsurance provider 110 via a network 120. The network 120 can facilitateany type of data communication via any standard or technology (e.g.,GSM, CDMA, TDMA, WCDMA, LTE, EDGE, OFDM, GPRS, EV-DO, UWB, IEEE 802including Ethernet, WiMAX, and/or others). The insurance provider 110can be any individual, group of individuals, company, corporation, orother type of entity that can offer and issue insurance policies forcustomers, such as a vehicle insurance policy for the vehicle 105.According to embodiments, the insurance provider 110 can include one ormore processing server(s) 125 configured to facilitate thefunctionalities as discussed herein. Although FIG. 1 depicts theprocessing server 125 as a part of the insurance provider 110, it shouldbe appreciated that the processing server 125 can be separate from (andconnected to or accessible by) the insurance provider 110.

According to embodiments, the insurance provider 110 may issue, to thevehicle operator, a distance-based insurance policy associated with thevehicle 105. In particular, the distance-based insurance policy mayprovide coverage for the vehicle operator and/or the vehicle 105.Specifically, the distance-based insurance policy provides coverage fora certain amount of distance units to be driven by the vehicle 105. Forexample, a distance-based insurance policy may provide coverage for 50miles, 500 miles, or other distances.

Generally, when the vehicle operator purchases a distance-basedinsurance policy from the insurance provider 110, the vehicle operatorwill provide an initial odometer reading of the vehicle 105 to theinsurance provider 110. In some cases, the insurance provider 110 mayobtain the initial odometer reading directly from the electronic device106 or another device associated with the vehicle 105 (e.g., an on-boardcomponent). Accordingly, the distance-based insurance policy has an“expiration odometer value” defined as the sum of the initial odometerreading and the specified amount of distance units covered by theinsurance policy. For example, if the initial odometer reading is 80,500miles and the specified amount of distance units is 500 miles, theexpiration odometer value is 81,000 miles.

The distance-based insurance policies may also specify an expirationdate or time, or policy term, within which the vehicle operators may usetheir distance units (e.g., by driving their vehicles). For example, ifa distance-based insurance policy insures 500 miles and has a policyterm of 6 months, then the vehicle operator (and/or the vehicle 105,depending on the coverage) is insured for an operating distance of 500miles assuming that those miles are driven within the 6 month policyterm. In embodiments, the unused distance units expire or lapse uponexpiration of the policy term. Therefore, absent a renewal or purchaseof additional distance units, the vehicle operator and/or the vehicle105 will not be insured past the policy term, even if there remain anyunused distance units. For example, if a distance-based insurance policyis in force starting on January 1 and has a 6 month policy term, theexpiration date of the policy is June 30, whereby neither the vehicleoperator nor the vehicle 105 is insured according to the policybeginning on July 1, even if there are unused distance units.

According to the present embodiments, the insurance provider 110 isconfigured to process refunds, credits, or the like (generally:“credits”) for any distance units that are unused as of the end of apolicy term for a distance-based insurance policy. The insuranceprovider 110 is configured to maintain accounts for the vehicleoperators, whereby the accounts specify the terms of the distance-basedinsurance policies. The insurance provider 110 may also determine anappropriate amount of credits and apply the credits to the accounts.

In some cases, the credits may be in the form of “rollover” distanceunits. For example, if a distance-based insurance policy covers 500miles and at the end of the policy term there are 40 unused miles, thenthese 40 unused miles may be deemed as rollover miles and the insuranceprovider 110 may credit these 40 miles to an account of thecorresponding vehicle operator. In other cases, the credits may be inthe form of a monetary credit (i.e., cash or cash equivalent), wherebyany unused distance units may have an associated value that theinsurance provider 110 can use to calculate the monetary credit owed toa vehicle operator. For example, if a vehicle operator has 20 unusedmiles at the end of the policy term and each unused mile has a cashvalue of $0.20, then the insurance provider 110 can determine that thevehicle operator is owed $4.00 and can credit an account of the vehicleoperator, such as by processing a “refund,” issuing a check or otherpayment, adding to an account balance, or performing another refund. Thecredit may also be in other forms, such as a credit with the insuranceprovider 110, a discount on subsequent insurance products, or othertypes of credit.

The processing server 125 can be coupled to a database 115 configured tostore data associated with vehicle insurance policies. Further, thedatabase 115 may store account data associated with accounts ofcustomers. The processing server 125 may be configured to monitorexpiration dates of the distance-based insurance policies, as well asprocess appropriate refunds or credits according to any unused distanceunits. In some embodiments, the processing server 125 may alsofacilitate the purchase of additional or renewal insurance policies forthe customers.

Referring to FIG. 2, illustrated is a signal diagram 200 associated withprocessing credits associated with distance-based insurance policies. Inparticular, FIG. 2 includes a vehicle/customer device 206 (such as theelectronic device 106 as described with respect to FIG. 1) and aninsurance provider 210 (such as the insurance provider 110 as describedwith respect to FIG. 1). It should be appreciated that thevehicle/customer device 206 may include any electronic device associatedwith the vehicle (e.g., an on-board dash system) and/or any electronicdevice associated with a user/driver/operator of the vehicle (e.g., avehicle operator's smartphone, laptop, etc.). Although only onevehicle/customer device 206 is depicted in FIG. 2, it should beappreciated that the insurance provider 210 may communicate withmultiple vehicle/customer devices 206 to process credits associated withdistance-based insurance policies.

The signal diagram 200 may begin when a customer (i.e., vehicleoperator) uses the vehicle/customer device 206 to send a request (222)to the insurance provider 210 for a distance-based insurance policy.Generally, the distance-based insurance policy provides insurancecoverage for the vehicle and the vehicle operator for a set amount ofdistance units (e.g., miles, kilometers, etc.). The customer may use thevehicle/customer device 206 to provide (224) an initial odometerreading, and optionally a desired amount of distance units and a desiredpolicy term. For example, the customer may request an insurance policyfor 1,000 miles having a policy term of 6 months. It should beappreciated that the customer may provide the initial odometer readingmanually (e.g., by entering the odometer reading into an application ofthe vehicle/customer device 206) or via an indirect channel (e.g.,taking a picture of the odometer in the vehicle and transmitting thepicture to the insurance provider 110). Further, the vehicle/customerdevice 206 may be configured to automatically provide the initialodometer reading to the insurance provider 210. It should be appreciatedthat other techniques and channels for transmitting the initial odometerreading are envisioned.

The insurance provider 210 may assess an underwriting risk of thecustomer based on various customer data, as known in the art, andprovide an insurance quote to the vehicle/customer device 206. Theinsurance quote may offer a distance-based insurance policy with termsthat are the same as or different from the originally-requested terms(e.g., fewer or more distance units, shorter or longer policy term,etc.). The vehicle/customer device 206 and the insurance provider 210may facilitate (226) a purchase transaction for the distance-basedinsurance policy according to the insurance quote, after which thedistance-based insurance policy may be deemed active. Accordingly, theinitial odometer reading may serve as the “starting point” for theinsurance policy. The insurance provider 210 can calculate and record(227) an expiration odometer reading, which can be defined as the sum ofthe initial odometer reading and the amount of distance units specifiedby the insurance policy. It should be appreciated that the customer mayfacilitate the purchase transaction and the terms of the distance-basedinsurance policy via other techniques or channels, such as via a phonecall with the insurance provider 210 or via meeting with an agent of theinsurance provider 210.

At a specified time or date, the policy term of the insurance policyexpires, as indicated by 229 in FIG. 2. Upon expiration of the policyterm, the insurance provider 210 can request (228) the vehicle/customerdevice 206 for a subsequent odometer reading, whereby the subsequentodometer reading represents the odometer reading of the vehicle at ornear the expiration time/date of the policy term. The vehicle/customerdevice 206 can provide (230) the subsequent odometer reading to theinsurance provider 210, for example via one or more manual or automatictechniques as discussed herein. Based on the expiration odometer valueand the subsequent odometer reading, the insurance provider 210 candetermine (232) if any unused distance units remain. For example, if theinitial odometer reading was 12,000 miles, the insurance policy covered1,000 miles (resulting in an expiration odometer value of 13,000 miles),and the subsequent odometer reading is 12,900 miles, then there is atotal of 100 unused miles. If the insurance provider 210 determines thatthere are no distance units remaining (“NO”), the insurance provider 210can notify (234) the customer of any renewal or repurchase options, andthe customer may optionally complete an additional purchase transactionfor a subsequent or additional insurance policy.

If the insurance provider 210 determines that there are remaining unuseddistance units (“YES”), the insurance provider 210 can calculate (236) avalue or credit associated with the unused distance units. In someembodiments, the insurance provider 210 may designate any unuseddistance units as “rollover” distance units (e.g., on a 1-1 basis, 2-1basis, or other bases) that may be applied towards an additional orsubsequent distance-based insurance policy. In other embodiments, theinsurance provider 210 may convert any unused distance units into one ormore discounts that may be applied to an additional or subsequentinsurance policy, or to other products or services. For example, if apolicy term ends with 500 unused distance units, then the insuranceprovider may determine that the 500 unused distance miles are worth a20% off discount on a subsequent distance-based insurance policy. Infurther embodiments, the insurance provider 210 may convert any unuseddistance units into insurance provider 210 credits (i.e., a valueaccepted as monetary payment by the insurance provider 210) that may beapplied to an additional or subsequent insurance policy.

In still further embodiments, the insurance provider 210 may convert anyunused distance units into cash or a cash equivalent. In particular,each unused distance unit may have a set or variable cash value, whichmay be commensurate with the policy rate for the distance-basedinsurance policy. In some cases, the cash or cash equivalent may be inthe form of an investment asset that may be applied to an insurancepolicy renewal and that may accrue value over time. Accordingly, thecustomer is able to build equity in the distance-based insurance policy,similar to how cash values accrue in some life insurance policies. Inembodiments, the value of this type of investment asset may be more thana calculated cash value for the same amount of unused distance units, inan effort to incentivize the customer to purchase insurance renewals.

In some embodiments, the insurance provider 210 may offer (238) one ormore credit options to the customer, for the customer to select adesired type of credit. For example, the insurance provider may offerthe customer a cash value, rollover distance units, or a discount, or acombination thereof. The customer may use the vehicle/customer device206 to select a credit option and provide (240) the selection to theinsurance provider 210. The insurance provider 210 can apply (246) thedetermined or selected type of credit to an account of the customer. Forexample, the insurance provider 210 can apply rollover distance units toa customer account. For further example, the insurance provider 210 candeposit money into an account of the customer (or physically mail acheck to the customer). The insurance provider 210 can also notify (244)the customer of the account credit.

FIGS. 3A-3D illustrate example interfaces associated with processingvarious types of credits associated with distance-based vehicleinsurance policies. A vehicle or a customer device (e.g., an on-boarddash system, a smartphone, etc.) may be configured to display theinterfaces and receive selections and inputs via the interfaces. Forexample, a dedicated application that is configured to operate on thevehicle or consumer device may display the interfaces. It should beappreciated that the interfaces are merely examples and that alternativeor additional content is envisioned. Further, it should be appreciatedthat alternative devices or machines may display the example interfaces.

FIG. 3A illustrates an interface 348 that notifies a customer of anexpiration of a policy term for a distance-based insurance policy. Inembodiments, an insurance provider may notify the vehicle/customerdevice when the policy term lapses, which can cause the vehicle/customerdevice to display the interface 348. The interface 348 in FIG. 3Aenables the customer to enter, via an input box 349, the currentodometer reading of the vehicle having the insurance policy. It shouldbe appreciated that the current odometer reading may be identifiedmanually or automatically. The interface 348 may also include a “submit”selection 347 that, upon selection by the customer, causes thevehicle/customer device to transmit the current odometer reading valueto the insurance provider. Of course, the insurance provider candetermine whether there are unused distance units based on the currentodometer reading.

FIG. 3B illustrates an interface 350 that notifies the customer of anyunused distance units that remain from the distance-based insurancepolicy. In particular, the interface 350 indicates that the customer has252 unused miles, an amount which may be calculated based on the currentodometer reading input into 349 and according to the techniques asdiscussed herein. The interface 350 also indicates an option forreviewing various credit options for the unused miles, which thecustomer may choose to review (or not review) via a “no” selection 351or a “yes” selection 352.

FIG. 3C illustrates an interface 355 that presents credit options forthe unused distance units. According to embodiments, the insuranceprovider may calculate the credit options based on the amount of unuseddistance units (as shown: 252 miles). As shown in FIG. 3C, the creditoptions include an option for rollover miles, a 10% discount on arenewal insurance policy, $25.00 cash, and $35.00 cash accrual for arenewal policy. The interface 355 enables the customer to select one ofthe credit options via radio buttons (as shown: the $25.00 cash option356). Further, the interface 355 includes a “cancel” selection 357 thatenables the customer to exit the credit selection processing and a“submit” selection 358 that enables the customer to submit the selectedcredit option to the insurance provider.

FIG. 3D illustrates an interface 360 that notifies the customer of thestatus of the selected credit option. As shown in FIG. 3D, the interface360 informs the customer that $25.00 has been deposited into his or herbank account. The interface 360 also indicates an option for reviewingoptions to purchase a renewal insurance policy, which the customer maychoose to review (or not review) via a “no thanks” selection 361 or a“yes” selection 362.

Referring to FIG. 4, depicted is a block diagram of an example method400 for crediting a customer having a distance-based insurance policyassociated with a vehicle. The method 400 may be facilitated between theinsurance provider 110 (and specifically the processing server 125) asdepicted in FIG. 1 and a customer associated with the vehicle. Thecustomer may access any type of electronic or computing device (such asthe electronic device 106) to provide data and make appropriateselections.

The insurance provider can receive (block 405), from the customer, arequest for a distance-based insurance policy associated with thevehicle, as well as an initial odometer reading of the vehicle. In someembodiments, the request can include a desired amount of distance unitsfor the distance-based insurance policy. The insurance provider canfacilitate (block 410) a purchase transaction with the customer for thedistance-based insurance policy, where the distance-based insurancepolicy expires at a pre-determined time (i.e., has a specified policyterm). The distance-based insurance policy also specifies an amount ofdistance units (which may be the same as or different from the desiredamount of distance units). The insurance provider can calculate andrecord (block 415) an expiration odometer value. In particular, theexpiration odometer value can be defined as a sum of the initialodometer reading and the amount of distance units specified by theinsurance policy.

Line 416 of the method 400 represents an expiration of thepre-determined time (i.e., an expiration of the policy term) for thedistance-based insurance policy. At block 420, the insurance providercan request a subsequent odometer reading of the vehicle after thepre-determined time expires. According to embodiments, the subsequentodometer reading can be automatically retrieved or manually inputted bythe customer. In either case, the insurance provider can receive (block425) the subsequent odometer reading of the vehicle. The insuranceprovider can determine (block 430) whether the expiration odometer valuehas been reached. In particular, the insurance provider can compare thesubsequent odometer reading with the expiration odometer value todetermine whether the subsequent odometer reading meets or exceeds theexpiration odometer value.

If the insurance provider determines that the expiration odometer valuehas been reached (“YES”), processing can end or proceed to any otherfunctionality. If the insurance provider determines that the expirationodometer value has not been reached (“NO”), processing can proceed toblock 435 at which the insurance provider can calculate a difference indistance between the subsequent odometer reading and the expirationodometer value, where the difference in distance represents the unuseddistance units.

The insurance provider can next calculate (block 440) a credit based onthe difference in distance. In embodiments, the credit may be in theform of a credit amount of distance units (or “rollover” distance units)according to the difference in distance. In other embodiments, thecredit may be in the form of a monetary credit (e.g., cash or cashequivalent). In further embodiments, the credit may be in the form of amonetary accrual amount (e.g., a cash accrual policy), whereby thecustomer may choose whether to receive the monetary value of the creditor have an account (e.g., an investment account) credited with themonetary accrual amount. Moreover, in embodiments, the credit may be inthe form of a discount offer, such as a discount offer for a subsequentor further insurance policy term. The insurance provider can apply(block 445) the credit to an account of the customer. In some cases, forexample if the credit is a monetary credit, the insurance provider maydeposit the monetary credit into a bank account of the customer (or senda check to the customer). Otherwise, the insurance provider can updatethe account of the customer according to the type of the credit and thevalue of the credit.

FIG. 5 illustrates a diagram of an example processing server 525 (suchas the processing server 125 discussed with respect to FIG. 1) in whichthe functionalities as discussed herein may be implemented. It should beappreciated that the processing server 525 can be associated with aninsurance provider, as discussed herein.

The processing server 525 can include a processor 522 as well as amemory 578. The memory 578 can store an operating system 579 capable offacilitating the functionalities as discussed herein as well as a set ofapplications 575 (i.e., machine readable instructions). For example, oneof the set of applications 575 can be a policy processing application584 configured to facilitate the offering and purchase of distance-basedinsurance policies. It should be appreciated that other applications areenvisioned.

The processor 522 can interface with the memory 578 to execute theoperating system 579 and the set of applications 575. According toembodiments, the memory 578 can also include customer accountinformation 580 that includes information related to accounts ofcustomers, including insurance policies and credits associatedtherewith. The policy processing application 584 may interface with thecustomer account information 580 to retrieve relevant information thatthe policy processing application 584 may use to process insurancepolicies and terms associated therewith. The memory 578 can include oneor more forms of volatile and/or non-volatile, fixed and/or removablememory, such as read-only memory (ROM), electronic programmableread-only memory (EPROM), random access memory (RAM), erasableelectronic programmable read-only memory (EEPROM), and/or other harddrives, flash memory, MicroSD cards, and others.

The processing server 525 can further include a communication module 577configured to communicate data via one or more networks 520. Accordingto some embodiments, the communication module 577 can include one ormore transceivers (e.g., WWAN, WLAN, and/or WPAN transceivers)functioning in accordance with IEEE standards, 3GPP standards, or otherstandards, and configured to receive and transmit data via one or moreexternal ports 576. For example, the communication module 577 can send,via the network 520, requests for odometer information and/or creditoptions and receive relevant data and selections. The processing server525 may further include a user interface 581 configured to presentinformation to a user and/or receive inputs from the user. As shown inFIG. 5, the user interface 581 includes a display screen 582 and I/Ocomponents 583 (e.g., ports, capacitive or resistive touch sensitiveinput panels, keys, buttons, lights, LEDs, speakers, microphones).According to embodiments, the user may access the processing server 525via the user interface 581 to process insurance policies and/or performother functions. In some embodiments, the processing server 525 canperform the functionalities as discussed herein as part of a “cloud”network or can otherwise communicate with other hardware or softwarecomponents within the cloud to send, retrieve, or otherwise analyzedata.

In general, a computer program product in accordance with an embodimentincludes a computer usable storage medium (e.g., standard random accessmemory (RAM), an optical disc, a universal serial bus (USB) drive, orthe like) having computer-readable program code embodied therein,wherein the computer-readable program code is adapted to be executed bythe processor 522 (e.g., working in connection with the operating system579) to facilitate the functions as described herein. In this regard,the program code may be implemented in any desired language, and may beimplemented as machine code, assembly code, byte code, interpretablesource code or the like (e.g., via C, C++, Java, Actionscript,Objective-C, Javascript, CSS, XML). In some embodiments, the computerprogram product may be part of a cloud network of resources.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Additionally, certain embodiments are described herein as includinglogic or a number of routines, subroutines, applications, orinstructions. These may constitute either software (e.g., code embodiedon a non-transitory, machine-readable medium) or hardware. In hardware,the routines, etc., are tangible units capable of performing certainoperations and may be configured or arranged in a certain manner. Inexample embodiments, one or more computer systems (e.g., a standalone,client or server computer system) or one or more hardware modules of acomputer system (e.g., a processor or a group of processors) may beconfigured by software (e.g., an application or application portion) asa hardware module that operates to perform certain operations asdescribed herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) may bedriven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. Considering embodiments inwhich hardware modules are temporarily configured (e.g., programmed),each of the hardware modules need not be configured or instantiated atany one instance in time. For example, where the hardware modulescomprise a general-purpose processor configured using software, thegeneral-purpose processor may be configured as respective differenthardware modules at different times. Software may accordingly configurea processor, for example, to constitute a particular hardware module atone instance of time and to constitute a different hardware module at adifferent instance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or more processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location (e.g., within a homeenvironment, an office environment, or a server farm). In other exampleembodiments, the one or more processors or processor-implemented modulesmay be distributed across a number of geographic locations.

It should also be understood that, unless a term is expressly defined inthis patent using the sentence “As used herein, the term ‘______’ ishereby defined to mean . . . ” or a similar sentence, there is no intentto limit the meaning of that term, either expressly or by implication,beyond its plain or ordinary meaning, and such term should not beinterpreted to be limited in scope based on any statement made in anysection of this patent (other than the language of the claims). To theextent that any term recited in the claims at the end of this disclosureis referred to in this disclosure in a manner consistent with a singlemeaning, that is done for sake of clarity only so as to not confuse thereader, and it is not intended that such claim term be limited, byimplication or otherwise, to that single meaning. Finally, unless aclaim element is defined by reciting the word “means” and a functionwithout the recital of any structure, it is not intended that the scopeof any claim element be interpreted based on the application of 35U.S.C. §112, sixth paragraph.

The term “insurance policy,” as used herein, generally refers to acontract between an insurer and an insured. In exchange for paymentsfrom the insured, the insurer pays for damages to the insured which arecaused by covered perils, acts or events as specified by the language ofthe insurance policy. The payments from the insured are generallyreferred to as “premiums,” and typically are paid on behalf of theinsured upon purchase of the insurance policy or over time at periodicintervals. The amount of the damages payment is generally referred to asa “coverage amount” or a “face amount” of the insurance policy. Aninsurance policy may remain (or have a status or state of) “in-force”while premium payments are made during the term or length of coverage ofthe policy as indicated in the policy. An insurance policy may “lapse”(or have a status or state of “lapsed”), for example, when theparameters of the insurance policy have expired, when premium paymentsare not being paid, when a cash value of a policy falls below an amountspecified in the policy (e.g., for variable life or universal lifeinsurance policies), or if the insured or the insurer cancels thepolicy.

The terms “insurer,” “insuring party,” and “insurance provider” are usedinterchangeably herein to generally refer to a party or entity (e.g., abusiness or other organizational entity) that provides insuranceproducts, e.g., by offering and issuing insurance policies. Typically,but not necessarily, an insurance provider may be an insurance company.

Although the embodiments discussed herein relate to vehicle orautomobile insurance policies, it should be appreciated that aninsurance provider may offer or provide one or more different types ofinsurance policies. Other types of insurance policies may include, forexample, homeowners insurance; condominium owner insurance; renter'sinsurance; life insurance (e.g., whole-life, universal, variable, term);health insurance; disability insurance; long-term care insurance;annuities; business insurance (e.g., property, liability, commercialauto, workers compensation, professional and specialty liability, inlandmarine and mobile property, surety and fidelity bonds); boat insurance;insurance for catastrophic events such as flood, fire, volcano damageand the like; motorcycle insurance; farm and ranch insurance; personalarticle insurance; personal liability insurance; personal umbrellainsurance; community organization insurance (e.g., for associations,religious organizations, cooperatives); and other types of insuranceproducts. In embodiments as described herein, the insurance providersprocess claims related to insurance policies that cover one or moreproperties (e.g., homes, automobiles, personal articles), althoughprocessing other insurance policies is also envisioned.

The terms “insured,” “insured party,” “policyholder,” “customer,”“claimant,” and “potential claimant” are used interchangeably herein torefer to a person, party, or entity (e.g., a business or otherorganizational entity) that is covered by the insurance policy, e.g.,whose insured article or entity (e.g., property, life, health, auto,home, business) is covered by the policy. A “guarantor,” as used herein,generally refers to a person, party or entity that is responsible forpayment of the insurance premiums. The guarantor may or may not be thesame party as the insured, such as in situations when a guarantor haspower of attorney for the insured. An “annuitant,” as referred toherein, generally refers to a person, party or entity that is entitledto receive benefits from an annuity insurance product offered by theinsuring party. The annuitant may or may not be the same party as theguarantor.

Typically, a person or customer (or an agent of the person or customer)of an insurance provider fills out an application for an insurancepolicy. In some cases, the data for an application may be automaticallydetermined or already associated with a potential customer. Theapplication may undergo underwriting to assess the eligibility of theparty and/or desired insured article or entity to be covered by theinsurance policy, and, in some cases, to determine any specific terms orconditions that are to be associated with the insurance policy, e.g.,amount of the premium, riders or exclusions, waivers, and the like. Uponapproval by underwriting, acceptance of the applicant to the terms orconditions, and payment of the initial premium, the insurance policy maybe in-force, (i.e., the policyholder is enrolled).

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. For example, some embodimentsmay be described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still cooperate or interact witheach other. The embodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the description. Thisdescription, and the claims that follow, should be read to include oneor at least one and the singular also includes the plural unless it isobvious that it is meant otherwise.

This detailed description is to be construed as examples and does notdescribe every possible embodiment, as describing every possibleembodiment would be impractical, if not impossible. One could implementnumerous alternate embodiments, using either current technology ortechnology developed after the filing date of this application.

What is claimed:
 1. A computer-implemented method of crediting customershaving vehicle insurance policies, the method comprising: facilitating,by a processor, a purchase transaction with a customer for adistance-based insurance policy associated with a vehicle, a coverageprovided by the distance-based insurance policy (1) is based on anexpiration odometer value defined as the sum of an initial odometerreading of the vehicle and an amount of distance units specified by thedistance-based insurance policy, and (2) expires at a pre-determinedtime; responsive to the pre-determined time expiring, receiving asubsequent odometer reading of the vehicle; based on the subsequentodometer reading, determining, by the processor, that the expirationodometer value has not been reached; and applying a credit to an accountof the customer.
 2. The computer-implemented method of claim 1, whereinapplying the credit to the account of the customer comprises:calculating a difference in distance between the subsequent odometerreading and the expiration odometer value; and applying the credit tothe account of the customer, the credit based on the difference indistance.
 3. The computer-implemented method of claim 2, whereinapplying the credit to the account of the customer comprises: creditingthe account of the customer with a credit of distance units according tothe different in distance.
 4. The computer-implemented method of claim2, wherein applying the credit to the account of the customer comprises:calculating a monetary credit based on the difference in distance; andapplying the monetary credit to the account of the customer.
 5. Thecomputer-implemented method of claim 2, wherein applying the credit tothe account of the customer comprises: calculating a discount offerbased on the difference in distance, the discount offer for use on afuture insurance policy term; and applying the discount offer to theaccount of the customer.
 6. The computer-implemented method of claim 2,wherein applying the credit to the account of the customer comprises:calculating, based on the difference in distance, (1) a monetary accrualamount and (2) a monetary credit; providing the customer with an optionto select, as a credit, either the monetary accrual amount or themonetary credit; receiving a selected credit from the customer; andprocessing the account of the customer based on the selected credit. 7.The computer-implemented method of claim 6, wherein when the selectedcredit is the monetary accrual amount, processing the account of thecustomer based on the selected credit comprises: crediting an account ofthe customer with the monetary accrual amount.
 8. Thecomputer-implemented method of claim 6, wherein when the selected creditis the monetary credit, processing the account of the customer based onthe selected credit comprises: applying the monetary credit to theaccount of the customer.
 9. The computer-implemented method of claim 1,wherein receiving the subsequent odometer reading of the vehiclecomprises: requesting the customer to provide the subsequent odometerreading; and receiving the subsequent odometer reading of the vehiclefrom at least one of an electronic device of the vehicle and anelectronic device of the customer.
 10. The computer-implemented methodof claim 1, wherein receiving the subsequent odometer reading of thevehicle comprises: responsive to the pre-determined time expiring,automatically requesting the customer to provide the subsequent odometerreading; and receiving the subsequent odometer reading from thecustomer.
 11. A system for crediting customers having vehicle insurancepolicies, comprising: a communication module adapted to communicatedata; a memory adapted to store non-transitory computer executableinstructions; and a processor adapted to interface with thecommunication module, wherein the processor is configured to execute thenon-transitory computer executable instructions to cause the processorto: facilitate a purchase transaction with a customer for adistance-based insurance policy associated with a vehicle, a coverageprovided by the distance-based insurance policy (1) is based on anexpiration odometer value defined as the sum of an initial odometerreading of the vehicle and an amount of distance units specified by thedistance-based insurance policy, and (2) expires at a pre-determinedtime, responsive to the pre-determined time expiring, receive asubsequent odometer reading of the vehicle via the communication module,based on the subsequent odometer reading, determine that the expirationodometer value has not been reached, and apply a credit to an account ofthe customer.
 12. The system of claim 11, wherein to apply the credit tothe account of the customer, the processor is configured to: calculate adifference in distance between the subsequent odometer reading and theexpiration odometer value, and apply the credit to the account of thecustomer, the credit based on the difference in distance.
 13. The systemof claim 12, wherein to apply the credit to the account of the customer,the processor is configured to: credit the account of the customer witha credit of distance units according to the different in distance. 14.The system of claim 12, wherein to apply the credit to the account ofthe customer, the processor is configured to: calculate a monetarycredit based on the difference in distance, and apply the monetarycredit to the account of the customer.
 15. The system of claim 12,wherein to apply the credit to the account of the customer, theprocessor is configured to: calculate a discount offer based on thedifference in distance, the discount offer for use on a future insurancepolicy term, and apply the discount offer to the account of thecustomer.
 16. The system of claim 12, wherein to apply the credit to theaccount of the customer, the processor is configured to: calculate,based on the difference in distance, (1) a monetary accrual amount and(2) a monetary credit, provide the customer with an option to select, asa credit, either the monetary accrual amount or the monetary credit,receive a selected credit from the customer via the communicationmodule, and process the account of the customer based on the selectedcredit.
 17. The system of claim 16, wherein to process the account ofthe customer when the selected credit is the monetary accrual amount,the processor is configured to: credit an account of the customer withthe monetary accrual amount.
 18. The system of claim 16, wherein toprocess the account of the customer when the selected credit is themonetary credit, the processor is configured to: apply the monetarycredit to the account of the customer.
 19. The system of claim 11,wherein to receive the subsequent odometer reading of the vehicle, theprocessor is configured to: request the customer to provide thesubsequent odometer reading, and receive, via the communication module,the subsequent odometer reading of the vehicle from at least one of anelectronic device of the vehicle and an electronic device of thecustomer.
 20. The system of claim 11, wherein to receive the subsequentodometer reading of the vehicle, the processor is configured to:responsive to the pre-determined time expiring, automatically requestthe customer to provide the subsequent odometer reading, and receive,via the communication module, the subsequent odometer reading from thecustomer.